Chromium video: odd-size videos no longer one column narrower - #613

Lane v4l2-vavpp, 3.2.12 set. Not merged by the lane (the coordinator merges the 3.2.12 set).

Odd-size video in Omarchy's Chromium (fixed here). Arch Linux ARM's Chromium decodes through OmacVM's V4L2 device. omacvm-vdecd makes its CAPTURE buffers at the picture's size rounded up to even (omacvm-vdecd.c:648, the module's step), and Chromium's GPU process imports each frame as one AR24 dma-buf at the picture's own size (853x480 of an 854x480 buffer). Mesa's virgl drops an import's size, so the Mac sampled the whole buffer: odd-size VP9 came out one column (853x480) or one column and row (1001x563) narrower. The visible size itself is not lost (the module answers COMPOSE with it, Chromium 153 wraps every frame with it).

The daemon now tells the Mac the picture's size for such buffers before Chromium gets them: one NOP with the OMLS payload of virgl-resource-logical-size.patch per 8 buffers, on the render node GBM made them on (src/vdec/guest/vdecd-logical.h). Only when the runtime says omacvm.valogical=1 (3.2.11 and newer); OMACVM_VA_LOGICAL=0 turns it off; even sizes send nothing. Guest only (Update VM), no module change.

Test: src/tests/vdecd-logical.sh (CI guest job, a stand-in for the kernel's ioctls): branch 16 ok; origin/main's src/vdec/guest fails (no vdecd-logical.h), on macOS and in the VM (Arch, GCC 16).

Rows (Mac mini M4, hidden 3 GB clone, 3.2.11 test app 9d2105b, Chromium 153.0.8010.36, video-geometry, all 6 VP9 clips each):

(The odd clips stay "WRONG" in video-geometry's verdict only by the test card's red-band count at odd sizes: mpv's CPU decoding has the same; the ratios are exact.) Chromium's imports (logged) unchanged. tccd 0, GPU restarts 0, cores 0.

Docs (docs/video-decode.md known issues), from #610's rows and this lane's:

• mpv's vavpp default (motion-adaptive) deinterlacing draws green: OmacVM's runtime, not Mesa. Mesa's deinterlacer (vl_deint_filter.c) declares its samplers without views (SAMP only) and reads the decoded pictures, plain 2D textures, with 2D-array lookups; virgl-shader-array-sampler-2d-view.patch maps such lookups to 2D only for samplers declared with a view, so the Mac's GL read zeros (Y=U=V=0). Mesa's driver alone the same, so not the shim. Row: Tests/virgl/test-const-ubo.c case 25 black on the current runtime, right with the fix. Fix: virgl: 2D_ARRAY lookups on samplers without a view read a 2D texture (motion-adaptive deinterlacing) #615 (runtime patch + test, run-regressions.py OK); not yet measured in a VM.
• YUV to YUV video processing (bob/weave copies) loses vertical detail on virgl: Mesa's gfx compositor uses its weave shader for progressive surfaces (vl_compositor.c in 26.2.5 and main). Each pair of rows comes out alike on surfaces whose height is a multiple of 16 (854x480, 1080p in 1088 rows) and on all of them with Mesa alone; with the shim, surfaces of other heights come out in another pattern (1000x562: last rows 556 557 558 559 560 560; 1000x568: 556 557 559 559 561 561), every row within one row of its place (the height decides: the shim declares 854x480 too, and it still pairs); with Mesa alone the last chroma row of 1000x562 is far off (32 for 80). Not OmacVM's. This is the "about one row off" of mpv vavpp=deint=bob on HEVC 1000x562 with Video: H.264 1080p and other coded-size videos at their own size in Chrome and mpv #610: Video: H.264 1080p and other coded-size videos at their own size in Chrome and mpv #610 shows the video processing's output exactly. The upstream draft (not posted) runs on OmacVM's 2D-view patch; it needs a reproduction on a stock driver before anyone posts it.
• The old known issue "VA-API conversions on the GPU give black pictures" was out of date since 3.2.0: hwdownload,format=bgra and scale_vaapi=format=bgra show the test card in place on 3.2.11 (h264-edge's rows, H.264 1080p and HEVC 1000x562). Rewritten to what holds (RGB, not bit for bit).

Track: work/tracks/v4l2-vavpp-odd.md.